home *** CD-ROM | disk | FTP | other *** search
/ Language/OS - Multiplatform Resource Library / LANGUAGE OS.iso / gnu / gptx-0_2.lha / gptx-0.2 / gptx.info < prev    next >
Text File  |  1991-10-09  |  36KB  |  804 lines
  1. Info file gptx.info, produced by Makeinfo, -*- Text -*- from input
  2. file /usr2/pinard/gptx/0.2/doc/gptx.texi.
  3.  
  4.    Copyright (C) 1990 Free Software Foundation, Inc.  Francois Pinard
  5. <pinard@iro.umontreal.ca>, 1988.
  6.  
  7.    This program is free software; you can redistribute it and/or modify
  8. it under the terms of the GNU General Public License as published by
  9. the Free Software Foundation; either version 1, or (at your option)
  10. any later version.
  11.  
  12.    This program is distributed in the hope that it will be useful, but
  13. WITHOUT ANY WARRANTY; without even the implied warranty of
  14. MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  15. General Public License for more details.
  16.  
  17.    You should have received a copy of the GNU General Public License
  18. along with this program; if not, write to the Free Software
  19. Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  20.  
  21. 
  22. File: gptx.info,  Node: Top,  Next: Usage,  Up: (DIR)
  23.  
  24. `gptx' - GNU permuted index generator
  25. =====================================
  26.  
  27.    This is the 0.2 alpha release of `gptx', the GNU version of a
  28. permuted index generator.  This software has the main goal of providing
  29. a `ptx' *almost* compatible replacement, able to handle small files
  30. quickly, while providing a platform for more development.
  31.  
  32.    This version reimplements and extends standard `ptx'.  Among other
  33. things, it can produce a readable "KWIC" (keywords in their context)
  34. without the need of `nroff', there is also an option to produce TeX
  35. compatible output.  This version does not yet handle huge input files,
  36. that is, those files which do not fit in memory all at once.
  37.  
  38.    *Please note* that an overall renaming of all options is
  39. foreseeable.  In fact, GNU ptx specifications are not frozen yet.
  40.  
  41. * Menu:
  42.  
  43. * Usage::    How to use the program, its options and parameters.
  44. * Regexps::    How a regular expression is written and used.
  45. * ptx mode::    In which ways `ptx' mode is different.
  46. * Future::    What are the development lines of this program.
  47.  
  48. 
  49. File: gptx.info,  Node: Usage,  Next: Regexps,  Prev: Top,  Up: Top
  50.  
  51. How to use this program
  52. -----------------------
  53.  
  54.    This tool reads a text file and essentially produces a permuted
  55. index, with each keyword in its context.  The calling sketch is one of:
  56.  
  57.      gptx [OPTION]... [INPUT]... >OUTPUT
  58.  
  59.    or:
  60.  
  61.      ptx [OPTION]... [INPUT [OUTPUT]]
  62.  
  63.    These are two different versions of one program.  When using `ptx'
  64. instead of `gptx', this implies built-in `ptx' compatibility mode,
  65. disallowing extensions, introducing some limitations, and changing
  66. several of the program's default option values.  This documentation
  67. describes both modes of operation.  See *Note ptx mode:: for an
  68. explicit list of differences.
  69.  
  70.    As usual, each option is represented by an hyphen followed by a
  71. single letter.  Some options require a parameter in the form of a
  72. decimal number or a file name, in which case the parameter follows the
  73. option after some whitespace.  Option letters may be grouped and tied
  74. together as a string which follows only one hyphen; if one of several
  75. of them require parameters, they should follow the combined options in
  76. the order of appearance of individual letters in the string. 
  77. Individual options are explained below.
  78.  
  79.    When *not* in `ptx' compatibility mode, there may be zero, one or
  80. several parameters after the options.  If there is no parameters, the
  81. program reads the standard input.  If there is one or several
  82. parameters, they give the name of input files, which are all read in
  83. turn; as if all the input files were concatenated.  However, there is a
  84. full contextual break between each file; and when automatic referencing
  85. is requested, file names and line numbers refer to individual text
  86. input files.  In all cases, the program produces the permuted index
  87. onto the standard output.
  88.  
  89.    When in `ptx' compatibility mode, besides the options, there may be
  90. zero, one or two parameters.  If there is no parameters, the program
  91. reads the standard input and produces the permuted index onto the
  92. standard output.  If there is only one parameter, it names the text
  93. file to be read instead of the standard input.  If two parameters are
  94. given, they give respectively the name of the file to read and the
  95. name of the file to produce.  *Be careful* to note that, in this case,
  96. the contents of file given by the second parameter is destroyed; this
  97. behaviour is dictated by compatibility; GNU standards discourage output
  98. parameters not introduced by an option.
  99.  
  100.    Note that for *any* file named as the value of an option or as an
  101. input text file, a single dash `-' may be used, in which case standard
  102. input is assumed.  However, it would not make sense to use this
  103. convention more than once per program invocation.
  104.  
  105. * Menu:
  106.  
  107. * General options::    Options which affect general program behaviour.
  108. * Charset selection::    Underlying character set considerations.
  109. * Input processing::    Input fields, contexts, and keyword selection.
  110. * Output formatting::    Types of output format, and sizing the fields.
  111.  
  112. 
  113. File: gptx.info,  Node: General options,  Next: Charset selection,  Up: Usage
  114.  
  115. General options
  116. ...............
  117.  
  118. `-C'
  119.      Prints a short note about the Copyright and copying conditions.
  120.  
  121. 
  122. File: gptx.info,  Node: Charset selection,  Next: Input processing,  Prev: General options,  Up: Usage
  123.  
  124. Charset selection
  125. .................
  126.  
  127.    As it is setup now, the program assumes that the input file is coded
  128. using 8-bit ISO 8859-1 code, also known as Latin-1 character set,
  129. *unless* if it is compiled for MS-DOS, in which case it uses the
  130. character set of the IBM-PC.  Compared to 7-bit ASCII, the set of
  131. characters which are letters is then different, this fact alters the
  132. behaviour of regular expression matching.  Thus, the default regular
  133. expression for a keyword allows foreign or diacriticized letters. 
  134. Keyword sorting, however, is still crude; it obeys the underlying
  135. character set ordering quite blindly.
  136.  
  137. `-f'
  138.      Fold lower case letters to upper case for sorting.
  139.  
  140. 
  141. File: gptx.info,  Node: Input processing,  Next: Output formatting,  Prev: Charset selection,  Up: Usage
  142.  
  143. Word selection
  144. ..............
  145.  
  146. `-b FILE'
  147.      This option is an alternative way to option `-W' for describing
  148.      which characters make up words.  This option introduces the name
  149.      of a file which contains a list of characters which can*not* be
  150.      part of one word, this file is called the "Break file".  Any
  151.      character which is not part of the Break file is a word
  152.      constituent.  If both options `-b' and `-W' are specified, then
  153.      `-W' has precedence and `-b' is ignored.
  154.  
  155.      In normal mode, the only way to avoid newline as a break
  156.      character is to write all the break characters in the file with
  157.      no newline at all, not even at the end of the file.  In `ptx'
  158.      compatibility mode, spaces, tabs and newlines are always
  159.      considered as break characters even if not included in the Break
  160.      file.
  161.  
  162. `-i FILE'
  163.      The file associated with this option contains a list of words
  164.      which will never be taken as keywords in concordance output.  It
  165.      is called the "Ignore file".  The file contains exactly one word
  166.      in each line; the end of line separation of words is not subject
  167.      to the value of the `-S' option.
  168.  
  169.      If not specified, there might be a default Ignore file.  Default
  170.      Ignore files are not necessarily the same in normal mode or in
  171.      `ptx' compatibility mode.  Unless changed by the local
  172.      installation, there is *no* default Ignore file in normal mode,
  173.      and the Ignore file is `/usr/lib/eign' in `ptx' compatibility
  174.      mode.  If you want to deactivate a default Ignore file, use
  175.      `/dev/null' instead.
  176.  
  177. `-o FILE'
  178.      The file associated with this option contains a list of words
  179.      which will be retained in concordance output, any word not
  180.      mentionned in this file is ignored.  The file is called the "Only
  181.      file".  The file contains exactly one word in each line; the end
  182.      of line separation of words is not subject to the value of the
  183.      `-S' option.
  184.  
  185.      There is no default for the Only file.  In the case there are
  186.      both an Only file and an Ignore file, a word will be subject to
  187.      be a keyword only if it is given in the Only file and not given
  188.      in the Ignore file.
  189.  
  190. `-r'
  191.      On each input line, the leading sequence of non white characters
  192.      will be taken to be a reference that has the purpose of
  193.      identifying this input line on the produced permuted index.  See
  194.      *Note Output formatting:: for more information about reference
  195.      production.  Using this option change the default value for
  196.      option `-S'.
  197.  
  198.      Using this option, the program does not try very hard to remove
  199.      references from contexts in output, but it succeeds in doing so
  200.      *when* the context ends exactly at the newline.  If option `-r'
  201.      is used with `-S' default value, or when in `ptx' compatibility
  202.      mode, this condition is always met and references are completely
  203.      excluded from the output contexts.
  204.  
  205. `-S REGEXP'
  206.      This option selects which regular expression will describe the
  207.      end of a line or the end of a sentence.  In fact, there is other
  208.      distinction between end of lines or end of sentences than the
  209.      effect of this regular expression, and input line boundaries have
  210.      no special significance outside this option.  By default, in
  211.      `ptx' compatibility mode or if `-r' option is used, end of lines
  212.      are used; in this case, the REGEXP used is very simple:
  213.  
  214.           \n
  215.  
  216.           In normal mode and if `-r' option is not used, by default, end of
  217.      sentences are used; the precise REGEX is imported from GNU emacs:
  218.  
  219.           [.?!][]\"')}]*\\($\\|\t\\|  \\)[ \t\n]*
  220.  
  221.           An empty REGEXP is equivalent to completly disabling end of line
  222.      or end of sentence recognition.  In this case, the whole file is
  223.      considered to be a single big line or sentence.  The user might
  224.      want to disallow all truncation flag generation as well, through
  225.      option `-F ""'.  On regular expression writing and usage, see
  226.      *Note Regexps::.
  227.  
  228.      When the keywords happen to be near the beginning of the input
  229.      line or sentence, this often creates an unused area at the
  230.      beginning of the output context line; when the keywords happen to
  231.      be near the end of the input line or sentence, this often creates
  232.      an unused area at the end of the output context line.  The
  233.      program tries to fill those unused areas by wrapping around
  234.      context in them; the tail of the input line or sentence is used
  235.      to fill the unused area on the left of the output line; the head
  236.      of the input line or sentence is used to fill the unused area on
  237.      the right of the output line.
  238.  
  239.      This option is not available when the program is operating `ptx'
  240.      compatibility mode.
  241.  
  242. `-W REGEXP'
  243.      This option selects which regular expression will describe each
  244.      keyword.  By default, in `ptx' compatibility mode, a word is
  245.      anything which ends with a space, a tab or a newline; the REGEXP
  246.      used is `[^ \t\n]+'.
  247.  
  248.      In normal mode, a word is a sequence of letters; the REGEXP used
  249.      is `\w+'.
  250.  
  251.      An empty REGEXP is equivalent to not using this option, letting
  252.      the default dive in.  On regular expression writing and usage, see
  253.      *Note Regexps::.
  254.  
  255.      This option is not available when the program is operating `ptx'
  256.      compatibility mode.
  257.  
  258. 
  259. File: gptx.info,  Node: Output formatting,  Prev: Input processing,  Up: Usage
  260.  
  261. Output formatting
  262. .................
  263.  
  264.    Output format is mainly controlled by `-O' and `-T' options,
  265. described in the table below.  However, when neither `-O' nor `-T' is
  266. selected, and if we are not running in `ptx' compatibility mode, the
  267. program choose an output format suited for a dumb terminal.  This is
  268. the default format when working in normal mode.  Each keyword
  269. occurrence is output to the center of one line, surrounded by its left
  270. and rigth contexts.  Each field is properly justified, so the
  271. concordance output could readily be observed.  As a special feature,
  272. if automatic references are selected by option `-A' and are output
  273. before the left context, that is, if option `-R' is *not* selected,
  274. then a colon is added after the reference; this nicely interfaces with
  275. GNU Emacs `next-error' processing.  In this default output format,
  276. each white space character, like newline and tab, is merely changed to
  277. exactly one space, with no special attempt to compress consecutive
  278. spaces.  This might change in the future.  Except for those white
  279. space characters, every other character of the underlying set of 256
  280. characters is transmitted verbatim.
  281.  
  282.    Output format is further controlled by the following options.
  283.  
  284. `-g NUMBER'
  285.      Select the size of the minimum white gap between the fields on
  286.      the output line.
  287.  
  288. `-w NUMBER'
  289.      Select the output maximum width of each final line.  If
  290.      references are used, they are included or excluded from the
  291.      output maximum width depending on the value of option `-R'.  If
  292.      this option is not selected, that is, when references are output
  293.      before the left context, the output maximum width takes into
  294.      account the maximum length of all references.  If this options is
  295.      selected, that is, when references are output after the right
  296.      context, the output maximum width does not take into account the
  297.      space taken by references, nor the gap that precedes them.
  298.  
  299. `-A'
  300.      Select automatic references.  Each input line will have an
  301.      automatic reference made up of the file name and the line
  302.      ordinal, with a single colon between them.  However, the file
  303.      name will be empty when standard input is being read.  If both
  304.      `-A' and `-r' are selected, then the input reference is still
  305.      read and skipped, but the automatic reference is used at output
  306.      time, overriding the input reference.
  307.  
  308.      This option is not available when the program is operating `ptx'
  309.      compatibility mode.
  310.  
  311. `-R'
  312.      In default output format, when option `-R' is not used, any
  313.      reference produced by the effect of options `-r' or `-A' are
  314.      given to the far right of output lines, after the right context. 
  315.      In default output format, when option `-R' is specified,
  316.      references are rather given to the beginning of each output line,
  317.      before the left context.  For any other output format, option
  318.      `-R' is almost ignored, except for the fact that the width of
  319.      references is *not* taken into account in total output width
  320.      given by `-w' whenever `-R' is selected.
  321.  
  322.      This option is not explicitely selectable when the program is
  323.      operating in `ptx' compatibility mode.  However, in this case, it
  324.      is always implicitely selected.
  325.  
  326. `-F STRING'
  327.      This option will request that any truncation in the output be
  328.      reported using the string STRING.  Most output fields
  329.      theoretically extend towards the beginning or the end of the
  330.      current line, or current sentence, as selected with option `-S'. 
  331.      But there is a maximum allowed output line width, changeable
  332.      through option `-w', which is further divided into space for
  333.      various output fields.  When a field has to be truncated because
  334.      cannot extend until the beginning or the end of the current line
  335.      to fit in the, then a truncation occurs.  By default, the string
  336.      used is a single slash, as in `-F /'.
  337.  
  338.      STRING may have more than one character, as in `-F ...'.  Also,
  339.      in the particular case STRING is empty (`-F ""'), truncation
  340.      flagging is disabled, and no truncation marks are appended in
  341.      this case.
  342.  
  343.      This option is not available when the program is operating `ptx'
  344.      compatibility mode.
  345.  
  346. `-O'
  347.      Choose an output format suitable for `nroff' or `troff'
  348.      processing.  Each output line will look like:
  349.  
  350.           .xx "TAIL" "BEFORE" "KEYWORD_AND_AFTER" "HEAD" "REF"
  351.  
  352.           so it will be possible to write an `.xx' roff macro to take care
  353.      of the output typesetting.  This is the default output format
  354.      when working in `ptx' compatibility mode.
  355.  
  356.      In this output format, each non-graphical character, like newline
  357.      and tab, is merely changed to exactly one space, with no special
  358.      attempt to compress consecutive spaces.  Each quote character:
  359.      `"' is doubled so it will be correctly processed by `nroff' or
  360.      `troff'.  All characters having their eight bit set are turned
  361.      into spaces in this version.  It is expectable that diacriticized
  362.      characters will be correctly expressed in `roff' terms if I learn
  363.      how to do this.  So, let me know how to improve this special
  364.      character processing.
  365.  
  366.      This option is not available when the program is operating `ptx'
  367.      compatibility mode.  In fact, it then becomes the default and
  368.      sole output format.
  369.  
  370. `-T'
  371.      Choose an output format suitable for TeX processing.  Each output
  372.      line will look like:
  373.  
  374.           \xx {TAIL}{BEFORE}{KEYWORD}{AFTER}{HEAD}{REF}
  375.  
  376.           so it will be possible to write write a `\xx' definition to take
  377.      care of the output typesetting.  Note that when references are
  378.      not being produced, that is, neither option `-A' nor option `-r'
  379.      is selected, the last parameter of each `\xx' call is inhibited.
  380.  
  381.      In this output format, some special characters, like `$', `%',
  382.      `&', `#' and `_' are automatically protected with a backslash. 
  383.      Curly brackets `{', `}' are also protected with a backslash, but
  384.      also enclosed in a pair of dollar signs to force mathematical
  385.      mode.  The backslash itself produces the sequence `\backslash{}'.
  386.       Circumflex and tilde diacritics produce the sequence `^\{ }' and
  387.      `~\{ }' respectively.  Other diacriticized characters of the
  388.      underlying character set produce an appropriate TeX sequence as
  389.      far as possible.  The other non-graphical characters, like
  390.      newline and tab, and all others characters which are not part of
  391.      ASCII, are merely changed to exactly one space, with no special
  392.      attempt to compress consecutive spaces.  Let me know how to
  393.      improve this special character processing for TeX.
  394.  
  395.      This option is not available when the program is operating `ptx'
  396.      compatibility mode.
  397.  
  398. 
  399. File: gptx.info,  Node: Regexps,  Next: ptx mode,  Prev: Usage,  Up: Top
  400.  
  401. Syntax of Regular Expressions
  402. -----------------------------
  403.  
  404.    Regular expressions have a syntax in which a few characters are
  405. special constructs and the rest are "ordinary".  An ordinary character
  406. is a simple regular expression which matches that character and
  407. nothing else.  The special characters are `$', `^', `.', `*', `+',
  408. `?', `[', `]' and `\'; no new special characters will be defined.  Any
  409. other character appearing in a regular expression is ordinary, unless
  410. a `\' precedes it.
  411.  
  412.    For example, `f' is not a special character, so it is ordinary, and
  413. therefore `f' is a regular expression that matches the string `f' and
  414. no other string.  (It does not match the string `ff'.)  Likewise, `o'
  415. is a regular expression that matches only `o'.
  416.  
  417.    Any two regular expressions A and B can be concatenated.  The
  418. result is a regular expression which matches a string if A matches
  419. some amount of the beginning of that string and B matches the rest of
  420. the string.
  421.  
  422.    As a simple example, we can concatenate the regular expressions `f'
  423. and `o' to get the regular expression `fo', which matches only the
  424. string `fo'.  Still trivial.  To do something nontrivial, you need to
  425. use one of the special characters.  Here is a list of them.
  426.  
  427. `. (Period)'
  428.      is a special character that matches any single character except a
  429.      newline.  Using concatenation, we can make regular expressions
  430.      like `a.b' which matches any three-character string which begins
  431.      with `a' and ends with `b'.
  432.  
  433. `*'
  434.      is not a construct by itself; it is a suffix, which means the
  435.      preceding regular expression is to be repeated as many times as
  436.      possible.  In `fo*', the `*' applies to the `o', so `fo*' matches
  437.      one `f' followed by any number of `o's.  The case of zero `o's is
  438.      allowed: `fo*' does match `f'.
  439.  
  440.      `*' always applies to the smallest possible preceding expression.
  441.       Thus, `fo*' has a repeating `o', not a repeating `fo'.
  442.  
  443.      The matcher processes a `*' construct by matching, immediately,
  444.      as many repetitions as can be found.  Then it continues with the
  445.      rest of the pattern.  If that fails, backtracking occurs,
  446.      discarding some of the matches of the `*'-modified construct in
  447.      case that makes it possible to match the rest of the pattern. 
  448.      For example, matching `ca*ar' against the string `caaar', the
  449.      `a*' first tries to match all three `a's; but the rest of the
  450.      pattern is `ar' and there is only `r' left to match, so this try
  451.      fails.  The next alternative is for `a*' to match only two `a's. 
  452.      With this choice, the rest of the regexp matches successfully.
  453.  
  454. `+'
  455.      Is a suffix character similar to `*' except that it requires that
  456.      the preceding expression be matched at least once.  So, for
  457.      example, `ca+r' will match the strings `car' and `caaaar' but not
  458.      the string `cr', whereas `ca*r' would match all three strings.
  459.  
  460. `?'
  461.      Is a suffix character similar to `*' except that it can match the
  462.      preceding expression either once or not at all.  For example,
  463.      `ca?r' will match `car' or `cr'; nothing else.
  464.  
  465. `[ ... ]'
  466.      `[' begins a "character set", which is terminated by a `]'.  In
  467.      the simplest case, the characters between the two form the set. 
  468.      Thus, `[ad]' matches either one `a' or one `d', and `[ad]*'
  469.      matches any string composed of just `a's and `d's (including the
  470.      empty string), from which it follows that `c[ad]*r' matches `cr',
  471.      `car', `cdr', `caddaar', etc.
  472.  
  473.      Character ranges can also be included in a character set, by
  474.      writing two characters with a `-' between them.  Thus, `[a-z]'
  475.      matches any lower-case letter.  Ranges may be intermixed freely
  476.      with individual characters, as in `[a-z$%.]', which matches any
  477.      lower case letter or `$', `%' or period.
  478.  
  479.      Note that the usual special characters are not special any more
  480.      inside a character set.  A completely different set of special
  481.      characters exists inside character sets: `]', `-' and `^'.
  482.  
  483.      To include a `]' in a character set, you must make it the first
  484.      character.  For example, `[]a]' matches `]' or `a'.  To include a
  485.      `-', write `--', which is a range containing only `-'.  To
  486.      include `^', make it other than the first character in the set.
  487.  
  488. `[^ ... ]'
  489.      `[^' begins a "complement character set", which matches any
  490.      character except the ones specified.  Thus, `[^a-z0-9A-Z]'
  491.      matches all characters except letters and digits.
  492.  
  493.      `^' is not special in a character set unless it is the first
  494.      character.  The character following the `^' is treated as if it
  495.      were first (`-' and `]' are not special there).
  496.  
  497.      Note that a complement character set can match a newline, unless
  498.      newline is mentioned as one of the characters not to match.
  499.  
  500. `^'
  501.      is a special character that matches the empty string, but only if
  502.      at the beginning of a line in the text being matched.  Otherwise
  503.      it fails to match anything.  Thus, `^foo' matches a `foo' which
  504.      occurs at the beginning of a line.
  505.  
  506. `$'
  507.      is similar to `^' but matches only at the end of a line.  Thus,
  508.      `xx*$' matches a string of one `x' or more at the end of a line.
  509.  
  510. `\'
  511.      has two functions: it quotes the special characters (including
  512.      `\'), and it introduces additional special constructs.
  513.  
  514.      Because `\' quotes special characters, `\$' is a regular
  515.      expression which matches only `$', and `\[' is a regular
  516.      expression which matches only `[', and so on.
  517.  
  518.    Note: for historical compatibility, special characters are treated
  519. as ordinary ones if they are in contexts where their special meanings
  520. make no sense.  For example, `*foo' treats `*' as ordinary since there
  521. is no preceding expression on which the `*' can act.  It is poor
  522. practice to depend on this behavior; better to quote the special
  523. character anyway, regardless of where is appears.
  524.  
  525.    For the most part, `\' followed by any character matches only that
  526. character.  However, there are several exceptions: characters which,
  527. when preceded by `\', are special constructs.  Such characters are
  528. always ordinary when encountered on their own.  Here is a table of `\'
  529. constructs.
  530.  
  531. `\|'
  532.      specifies an alternative.  Two regular expressions A and B with
  533.      `\|' in between form an expression that matches anything that
  534.      either A or B will match.
  535.  
  536.      Thus, `foo\|bar' matches either `foo' or `bar' but no other
  537.      string.
  538.  
  539.      `\|' applies to the largest possible surrounding expressions. 
  540.      Only a surrounding `\( ... \)' grouping can limit the grouping
  541.      power of `\|'.
  542.  
  543.      Full backtracking capability exists to handle multiple uses of
  544.      `\|'.
  545.  
  546. `\( ... \)'
  547.      is a grouping construct that serves three purposes:
  548.  
  549.        1. To enclose a set of `\|' alternatives for other operations. 
  550.           Thus, `\(foo\|bar\)x' matches either `foox' or `barx'.
  551.  
  552.        2. To enclose a complicated expression for the postfix `*' to
  553.           operate on.  Thus, `ba\(na\)*' matches `bananana', etc.,
  554.           with any (zero or more) number of `na' strings.
  555.  
  556.        3. To mark a matched substring for future reference.
  557.  
  558.           This last application is not a consequence of the idea of a
  559.      parenthetical grouping; it is a separate feature which happens to
  560.      be assigned as a second meaning to the same `\( ... \)' construct
  561.      because there is no conflict in practice between the two meanings. 
  562.      Here is an explanation of this feature:
  563.  
  564. `\DIGIT'
  565.      after the end of a `\( ... \)' construct, the matcher remembers
  566.      the beginning and end of the text matched by that construct. 
  567.      Then, later on in the regular expression, you can use `\'
  568.      followed by DIGIT to mean "match the same text matched the
  569.      DIGIT'th time by the `\( ... \)' construct."
  570.  
  571.      The strings matching the first nine `\( ... \)' constructs
  572.      appearing in a regular expression are assigned numbers 1 through
  573.      9 in order that the open-parentheses appear in the regular
  574.      expression.  `\1' through `\9' may be used to refer to the text
  575.      matched by the corresponding `\( ... \)' construct.
  576.  
  577.      For example, `\(.*\)\1' matches any newline-free string that is
  578.      composed of two identical halves.  The `\(.*\)' matches the first
  579.      half, which may be anything, but the `\1' that follows must match
  580.      the same exact text.
  581.  
  582. `\`'
  583.      matches the empty string, provided it is at the beginning of the
  584.      buffer.
  585.  
  586. `\''
  587.      matches the empty string, provided it is at the end of the buffer.
  588.  
  589. `\b'
  590.      matches the empty string, provided it is at the beginning or end
  591.      of a word.  Thus, `\bfoo\b' matches any occurrence of `foo' as a
  592.      separate word.  `\bballs?\b' matches `ball' or `balls' as a
  593.      separate word.
  594.  
  595. `\B'
  596.      matches the empty string, provided it is not at the beginning or
  597.      end of a word.
  598.  
  599. `\<'
  600.      matches the empty string, provided it is at the beginning of a
  601.      word.
  602.  
  603. `\>'
  604.      matches the empty string, provided it is at the end of a word.
  605.  
  606. `\w'
  607.      matches any word-constituent character.  The editor syntax table
  608.      determines which characters these are.
  609.  
  610. `\W'
  611.      matches any character that is not a word-constituent.
  612.  
  613.    Here is a complicated regexp, used by Emacs to recognize the end of
  614. a sentence together with any whitespace that follows.  It is given in
  615. Lisp syntax to enable you to distinguish the spaces from the tab
  616. characters.  In Lisp syntax, the string constant begins and ends with
  617. a double-quote.  `\"' stands for a double-quote as part of the regexp,
  618. `\\' for a backslash as part of the regexp, `\t' for a tab and `\n'
  619. for a newline.
  620.  
  621.      "[.?!][]\"')]*\\($\\|\t\\|  \\)[ \t\n]*"
  622.  
  623. This contains four parts in succession: a character set matching
  624. period, `?' or `!'; a character set matching close-brackets, quotes or
  625. parentheses, repeated any number of times; an alternative in
  626. backslash-parentheses that matches end-of-line, a tab or two spaces;
  627. and a character set matching whitespace characters, repeated any
  628. number of times.
  629.  
  630. 
  631. File: gptx.info,  Node: ptx mode,  Next: Future,  Prev: Regexps,  Up: Top
  632.  
  633. `ptx' compatibility mode
  634. ------------------------
  635.  
  636.    This section outlines the differences between this program and
  637. standard `ptx'.  For someone used to standard `ptx', here are some
  638. points worth noticing when not using `ptx' compatibility mode:
  639.  
  640.    * In normal mode, concordance output is not formatted for `troff' or
  641.      `nroff'.  By default, output is rather formatted for a dumb
  642.      terminal.  `troff' or `nroff' output may still be selected
  643.      through option `-O'.
  644.  
  645.    * In normal mode, unless `-R' option is used, the maximum reference
  646.      width is subtracted from the total output line width.  In `ptx'
  647.      compatibility mode, width of references are not taken into
  648.      account in the output line width computations.
  649.  
  650.    * In normal mode, all 256 characters, even `NUL's, are read and
  651.      processed from input file with no adverse effect.  No attempt is
  652.      made to limit this in `ptx' compatibility mode.  However, standard
  653.      `ptx' does not accept 8-bit characters, a few control characters
  654.      are rejected, and the tilde `~' is condemned.
  655.  
  656.    * In normal mode, input line length is limited by available memory.
  657.       No attempt is made to limit this in `ptx' compatibility mode. 
  658.      However, standard `ptx' processes only the first 200 characters in
  659.      each line.
  660.  
  661.    * In normal mode, the break (non-word) characters default to be
  662.      every character except letters.  In `ptx' compatibility mode, the
  663.      break characters default to space, tab and newline only.
  664.  
  665.    * In some circumstances, output lines are filled a little more
  666.      completely in normal mode than in `ptx' compatibility mode.  Even
  667.      in `ptx' mode, there are some slight disposition glitches this
  668.      program does not completely reproduce, even if it comes quite
  669.      close.
  670.  
  671.    * The Ignore file default in `ptx' compatibility mode is not the
  672.      same as in normal mode.  In default installation, default Ignore
  673.      files are `/usr/lib/eign' in `ptx' compatibility mode, and
  674.      nothing in normal mode.
  675.  
  676.    * Standard `ptx' disallows specifying both the Ignore file and the
  677.      Only file at the same time.  This version allows both, and
  678.      specifying an Only file does not inhibit processing the Ignore
  679.      file.
  680.  
  681. 
  682. File: gptx.info,  Node: Future,  Prev: ptx mode,  Up: Top
  683.  
  684. Development guidelines
  685. ----------------------
  686.  
  687.    This software is meant to evolve towards a concordance package for
  688. GNU, which should ideally be able to tackle true, real, big
  689. concordance jobs, while staying fast and of easy for little jobs. 
  690. Several packages of this kind are awfully slow, I'm trying to keep
  691. speed in mind.  I am interested in interactive query, but postpone
  692. burdening myself too much too soon about it.
  693.  
  694.    Here is a *What To Do Next* list, in expected execution order.
  695.  
  696.   1. Increase short term usability:
  697.  
  698.         * Support the program for the GNU community.  As directed by
  699.           user comments, test and debug the whole thing more fully,
  700.           and on bigger examples.  Solve portability glitches as long
  701.           as this do not induce too ugly things in the code.
  702.  
  703.         * Provide sample macros in the documentation.
  704.  
  705.         * Understand and mimic `-t' option, if I can.
  706.  
  707.         * See how TeX mode could be made more useful, and if a texinfo
  708.           mode would mean something to someone.
  709.  
  710.         * Sort keywords intelligently for Latin-1 code.  See how to
  711.           interface this character set with various output formats. 
  712.           Also, introduce options to inverse-sort and possibly to
  713.           reverse-sort.
  714.  
  715.         * Improve speed for Ignore and Only tables.  Consider hashing
  716.           instead of sorting.  Consider playing with obstacks to
  717.           digest them.
  718.  
  719.         * Provide better handling of format effectors obtained from
  720.           input, and also attempt white space compression on output
  721.           which would still maximize full output width usage.
  722.  
  723.   2. Provide multiple language support.
  724.  
  725.         Most of the boosting work should go along the line of fast
  726.      recognition of multiple and complex boundaries, which define
  727.      various `languages'.  Each such language has its own rules for
  728.      words, sentences, paragraphs, and reporting requests.  This is
  729.      less difficult than I first thought:
  730.  
  731.         * Recognize language modifiers with each option.  At least -b,
  732.           -i, -o, -W, -S, and also new language switcher options, will
  733.           have such modifiers.  Modifiers on language switchers will
  734.           allow or disallow language transitions.
  735.  
  736.         * Complete the transformation of underlying variables into
  737.           arrays in the code.
  738.  
  739.         * Implement a heap of positions in the input file.  There is
  740.           one entry in the heap for each compiled regexp; it is
  741.           initialized by a re_search after each regexp compile. 
  742.           Regexps reschedule themselves in the heap when their
  743.           position passes while scanning input.  In this way, looking
  744.           simultaneously for a lot of regexps should not be too
  745.           inefficient, once the scanning starts.  If this works ok,
  746.           maybe consider accepting regexps in Only and Ignore tables.
  747.  
  748.         * Merge with language processing boundary processing options,
  749.           really integrating -S processing as a special case.  Maybe,
  750.           implement several level of boundaries.  See how to implement
  751.           a stack of languages, for handling quotations.  See if more
  752.           sophisticated references could be handled as another special
  753.           case of a language.
  754.  
  755.   3. Tackle other aspects, in a more long term view:
  756.  
  757.         * Add options for statistics, frequency lists, referencing,
  758.           and all other prescreening tools and subsidiary tasks of
  759.           concordance production.
  760.  
  761.         * Develop an interactive mode.  Even better, construct a GNU
  762.           emacs interface.  I'm looking at Gene Myers
  763.           <gene@cs.arizona.edu> suffix arrays as a possible
  764.           implementation along those ideas.
  765.  
  766.         * Implement hooks so word classification and tagging should be
  767.           merged in.  See how to effectively hook in lemmatisation or
  768.           other morphological features.  It is far from being clear by
  769.           now how to interface this correctly, so some experimentation
  770.           is mandatory.
  771.  
  772.         * Profile and speed up the whole thing.
  773.  
  774.         * Make it work on small address space machines.  Consider
  775.           three levels of hugeness for files, and three corresponding
  776.           algorithms to make optimal use of memory.  The first case is
  777.           when all the input files and all the word references fit in
  778.           memory: this is the case currently implemented.  The second
  779.           case is when the files cannot fit all together in memory, but
  780.           the word references do.  The third case is when even the
  781.           word references cannot fit in memory.
  782.  
  783.         * There also are subsidiary developments for in-core
  784.           incremental sort routines as well as for external sort
  785.           packages.  The need for more flexible sort packages comes
  786.           partly from the fact that linguists use kinds of keys which
  787.           compare in unusual and more sophisticated ways.  GNU `sort'
  788.           has been released recently, and could evolve with `gptx'.
  789.  
  790.      
  791. 
  792. Tag Table:
  793. Node: Top870
  794. Node: Usage1976
  795. Node: General options4984
  796. Node: Charset selection5173
  797. Node: Input processing5957
  798. Node: Output formatting11403
  799. Node: Regexps18240
  800. Node: ptx mode28347
  801. Node: Future30649
  802. 
  803. End Tag Table
  804.